As may be appreciated, a typical computing device is subject to many security risks including attacks, security breaches, and the like. To at least partially protect against such security risks, methods and mechanisms have been established to impart levels of trust to various computing activities. For example, for a user to perform a relatively sensitive act such as changing a security setting or installing a new trusted root certificate, the user may be required to enter a credential such as a password or the like, where the credential may be employed to identify the user, where the credential may act to confirm that the user in fact requests the operation, and/or where the credential may be employed to confirm that the user in fact has the right to request the operation.
As should be appreciated, then, a nefarious entity without knowledge of such a credential cannot supply same to establish trust at the computing device. However, and significantly, one avenue of attack that may be employed by such a nefarious entity may be to supply an application that tricks or otherwise deceives the user that has knowledge of the credential into supplying same. For example, the application may appear to collect the credential from the user for one purpose but then may instead use the collected credential to effectuate another purpose.
Even if such a credential is not required, the user may be required to confirm a relatively sensitive act by selecting from among options to confirm or deny the operation. Here, and in a similar manner, a nefarious entity may trick or otherwise deceive the user into allowing an operation by displaying the options in an improper manner. For example, the nefarious entity may be able to supply an application that replaces a ‘deny’ option with a ‘confirm’ label, and vice versa.
Generally, the root of the problem may be summarized as the inability to distinguish between a lawful application that legitimately prompts the user to perform some relatively sensitive act and a malicious application that illegitimately prompts the user. In particular, a nefarious entity can readily supply such a malicious application that generates a prompt requesting a user to enter a credential to effectuate an operation, to select an option to confirm such an operation, or the like, where the malicious application is constructed to look like and even behave as a legitimate application.
Moreover, in at least some computing architectures, a malicious application can be constructed and operated to monitor and intercept inputs to a legitimate application, including an entered credential or the like. Furthermore, such a malicious application may also programmatically control a legitimate application such that the legitimate application dismisses user confirmation of sensitive acts. In such an instance, it may for example occur that a user supplies changes to the security settings of a legitimate firewall application on a computing device, but that the malicious application programmatically causes the legitimate application to ignore the changes such that the computing device is more vulnerable to attack.
At any rate, one method and mechanism to combat such a malicious application is to supply the computing device with a user desktop that is available to user processes during the normal course of operation of the computing device, and also to supply the computing device with a secure desktop that is ‘elevated’ from the user desktop in terms of security and from which more secure system processes are available. Notably, such secure desktop only allows an application to be executed therefrom if the application is recognized by the secure desktop as being trustworthy. As may be appreciated, such trustworthiness may be established in any appropriate manner, and may for example comprise the application having a non-revoked digital certificate or other proffering device from a source that is recognized by the secure desktop as being trustworthy. Thus, the secure desktop allows an application to be run thereon only after the application has been established as being trustworthy, and if the trustworthy application satisfies any other policy that the secure desktop enforces. Such a secure desktop is disclosed more fully in U.S. patent application Ser. No. 11/251,946, filed Oct. 17, 2005 and hereby incorporated by reference in its entirety.
Typically, the secure desktop is switched to from the user desktop when the computing device is required to perform a sensitive act. For example, the secure desktop may be called to adjust a privilege for a user or a process or the like. Similarly, the secure desktop may be called to securely confirm a sensitive act, securely input sensitive information, or the like. When a user application or the like calls to perform a sensitive act, the call is either received or intercepted such that the secure desktop performs the sensitive act. In doing so, the secure desktop may require that the user securely confirm performance of the sensitive act, perhaps by way of an entered credential or a confirmatory selection. Only after the user so securely confirms does the secure desktop in fact perform the sensitive act, as may be appreciated. The sensitive act is then performed at the secure desktop by way of a secure application, after which control returns to the user desktop and the user application that initiated the call. Inasmuch as the secure desktop performs the sensitive act by way of a secure application, a malicious entity that presumably cannot supply a secure application cannot trick or otherwise coerce the secure desktop into executing a non-trustworthy illegitimate application to perform a sensitive act.
It is to be appreciated that a desktop does not strictly speaking perform any act. Instead, an application may be executed on a corresponding desktop to perform an act. Of course, the desktop may perform some decision-making with regard to whether an application may execute thereon, and also with regard to specific acts the application may attempt. Generally, only a trustworthy application can execute on the secure desktop to display user interface subject matter in a space where a non-trustworthy user application cannot interfere. Likewise, only the non-trustworthy user application may only execute on the user desktop. Thus, it may be said that a user desktop is a ‘container’ for non-trustworthy user applications while a secure desktop is a container for a trustworthy secure application.
Inherent in the use of the secure desktop is the concept that the user at the computing device is being asked to make a good decision on when to allow a secure application to perform a sensitive act on the secure desktop. Thus, such user should be presented with an access interface that provides the user with reliable information such that the user can in fact make such a good decision based on the needs of the user and considerations of system protection. Unfortunately, a poor decision may result in the system being corrupted or otherwise left vulnerable to malicious attack by a nefarious entity or the like. Therefore, the access interface must be protected from attack by such a nefarious entity or the like.
However, and significantly, it has been found that the access interface is indeed vulnerable to attack by such a nefarious entity. Specifically, it has been demonstrated that inputs to the access interface can be altered or ‘spoofed’. For example, if the access interface includes one or more visual zones or ‘buttons’ that can be selected by way of a cursor or the like, the cursor can be made to appear to a user as selecting a deny button that denies permission to perform a sensitive act on the secure desktop, when in fact the cursor selects an accept or confirmatory button that allows such sensitive act on such secure desktop.
Thus, a nefarious entity may effectuate a nefarious application at the user desktop of a computing device, where the nefarious application attempts to commit some undesirable act by way of a sensitive act at the secure desktop. In such an instance, the user would typically be prompted on the user desktop to deny or allow such act, recognize that the act should be denied, and thus choose to select the deny button. Notably, though, the nefarious application or a related application can spoof the selection of the deny button on the user desktop to in fact be a selection of the accept button, and thereafter wreak havoc based on the performed sensitive act. For example, if the sensitive act is to elevate a privilege for the nefarious application, the nefarious application could employ the elevated privilege to delete files at the computing device, or even delete an account for the user at the computing device. As may be appreciated, such an attack is a specific example of a more general class of interface spoofing attacks, which are not believed to have a solution within a graphics/display subsystem of a computing device.
Accordingly, a need exists for a method and mechanism to render and present an access interface for obtaining permission to perform a sensitive act at a secure desktop, where the access interface is not susceptible to an interface spoofing attack. In particular, a need exists for a method and mechanism by which the access interface executes on the secure desktop to be presented to the user. Moreover, a need exists for such a method and mechanism whereby the access interface is presented to the user in an aesthetically pleasing and expected manner such that the user is not surprised by the presence of the interface and can be expected to make a good decision regarding whether to allow a secure application to be run at the secure desktop to elevate a privilege.